Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000093_owner-urn-ietf _Sat Mar 29 04:26:35 1997.msg

Internet Message Format | 1997-04-01 | 4KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id EAA11084
    for urn-ietf-out; Sat, 29 Mar 1997 04:26:35 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id EAA11079
    for <[e-mail]>; Sat, 29 Mar 1997 04:26:29 -0500 (EST)
Received: from beach.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA21677  (mail destined for [e-mail]); Sat, 29 Mar 97 04:26:27 -0500
Received: from beach.w3.org (beach.w3.org [207.8.37.250])
          by beach.w3.org (8.8.4/8.8.4) with SMTP
      id DAA16777; Sat, 29 Mar 1997 03:26:27 -0600
Message-Id: <[e-mail]>
Date: Sat, 29 Mar 1997 03:26:26 -0600
From: Dan Connolly <[e-mail]>
Organization: World Wide Web Consortium
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
Mime-Version: 1.0
To: [e-mail]
Subject: [URN] urn: prefix is a brand name?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Dan Connolly <[e-mail]>
Errors-To: [e-mail]

I found another one of the motivations for the urn: prefix,
(thanks for the pointer to the WAIS archive!)
and it worries me more than any of the other so far:

On Tue, 05 Nov 1996 23:16:17 -0500, Keith Moore wrote:
>This is why URNs need a URN: prefix -- because a lot of the value in
>having a URN name space with those properties is so *humans* can
>recognize a URN when they see it.

In effect, this says that urn: is intended to act as a sort
of trusted brand name, kinda like "RFC" in a way.

It seems to me that DUNS and ISBN already have that brand
name trust, and adding urn: on the front doesn't really
add anything.

The RFC brand name is based on the tradition of excellence
and the process of the IETF. It's trust in the IETF
as an institution. (Ironically, I gather that the term
'RFC' is being decommissioned because of misuse...)

Is this working group attempting to give urn: the same sort
of status? Are we setting the IETF up to be the institution
that guarantees that identifiers are managed well and
work reliably? I suppose that's what the NID requirements
document is all about. It delegates the bulk of the
work of operating the namespace, but squarely places ultimate
responsibilty on the IETF to review new NIDs.

But what about enforcement? Once a NID is registered, what's
to prevent it from running amok or going away?

It seems to me that draft-nid-req is making a commitment
on behalf of the IETF (or IANA) to maintain the urn: brand name
in perpetuity. I don't believe the IETF is the sort of
organization that can do that. Maintaining registries of
technical details like protocol port numbers is one thing,
but sitting at the root of the world's information hierarchy
is quite another. The IAHC says folks need $5M of liability
insurance to do that sort of thing.

By the way... Is the procss for registering a subdomain of .urn.net
the same as the process of allocating a new NID? If so,
that would seem to break the independence of namespaces
from resolution mechanisms.

If not, what are the
rules for the administration of the .urn.net domain?
It seems to me that the .urn.net is going to be more
relevant, since new records in .urn.net propagate
automatically, as opposed to traditional standards
deployment from NID registrations.

--
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21